[Debug Info] Gracefully handle invalid `String`/`Vec` by Walnut356 · Pull Request #155509 · rust-lang/rust

Walnut356 · 2026-04-19T07:02:25Z

Somewhat related to #150392.

Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value.

Additionally, if a String/Vec is in an "invalid" state due to niche optimization (capacity >= (1 << 63), common with Option<String>/Option<Vec<T>>), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like <try to read multiple GB of data from the debugee>.

I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty.

Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot.

rustbot · 2026-04-19T07:02:31Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @Mark-Simulacrum

Mark-Simulacrum

r=me with if wording fixed, happy to skip/defer the helper, up to you.

View changes since this review

Mark-Simulacrum · 2026-04-26T18:43:34Z


    if length <= 0:
        return '""'
+
+    no_hi_bit_max: int = 1 << ((pointer.GetByteSize() * 8) - 1)
+    # technically length isn't a NoHighBit<usize>, but if length should always be <= capacity


Suggested change

# technically length isn't a NoHighBit<usize>, but if length should always be <= capacity

# technically length isn't a NoHighBit<usize>, but length should always be <= capacity

Not sure what if was meaning to refer to here?

Mark-Simulacrum · 2026-04-26T18:44:58Z

-    else:
-        raise Exception("ReadMemory error: %s", error.GetCString())
+    try:
+        data = process.ReadMemory(pointer.GetValueAsUnsigned(), length, error)


Should we aim for all process.ReadMemory calls to be wrapped like this? Maybe we should define our own helper to push for that? E.g., StdPathSummaryProvider probably needs the same treatment?

Ah, yeah that's a good question. It's probably best to, since swig FFI exceptions cause such catastrophic issues.

StdPathSummaryProvider probably needs the same treatment

Atm Path and OsStr providers defer directly to the vec synthetic's get_num_children and get_child_at_index. Since the vec synthetic can now detect invalid state, it'll just report an empty string.

It wouldn't be a bad idea to switch to using process.ReadMemory eventually since it's significantly more performant, but it's not too urgent since paths are usually quite short.

rust/src/etc/lldb_providers.py

Line 368 in 2f43fe4

data = process.ReadMemory(start, length, error)

- doesn't that need to get wrapped with try catch?

🤦‍♂️ i might be blind lol

rustbot · 2026-04-26T18:45:57Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2026-04-27T06:16:54Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Walnut356 · 2026-04-27T08:29:40Z

@rustbot ready

Mark-Simulacrum · 2026-05-09T17:38:43Z

@bors r+

rust-bors · 2026-05-09T17:38:46Z

📌 Commit 0a4f89e has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…ulacrum [Debug Info] Gracefully handle invalid `String`/`Vec` Somewhat related to rust-lang#150392. Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value. Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>. I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty. Eventually this problem will be solved on LLDB's end via llvm/llvm-project#188487 or similar, but preventing issues on our end in the short term will help a lot.

JonathanBrouwer · 2026-05-09T20:09:59Z

@bors r-
#156371 (comment)

Not sure if this is spurious
@bors try jobs=aarch64-apple

rust-bors · 2026-05-09T20:10:06Z

This pull request was unapproved.

This PR was contained in a rollup (#156371), which was unapproved.

View changes since this unapproval

[Debug Info] Gracefully handle invalid `String`/`Vec` try-job: aarch64-apple

rust-bors · 2026-05-09T21:16:59Z

💔 Test for 89a60ef failed: CI. Failed job:

try - aarch64-apple (web logs, enhanced plaintext logs)

Walnut356 · 2026-05-10T05:54:36Z

Whoops, that's my bad. There was a small logic mistake which should be fixed now. I didn't catch the failure because tests/debuginfo/path.rs already fails on *-windows-gnu for other reasons, so I disregarded its failure on my end.

The test should no longer fail on *-windows-gnu once #155336 lands, or when I update the test suite as part of my GSoC project.

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 19, 2026

rustbot assigned Mark-Simulacrum Apr 19, 2026

Mark-Simulacrum requested changes Apr 26, 2026

View reviewed changes

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 26, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 26, 2026

gracefully handle invalid string/vec

e264a92

Walnut356 force-pushed the string_crash branch from 4529cdf to 3b9cf3e Compare April 27, 2026 06:16

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 27, 2026

Walnut356 force-pushed the string_crash branch from 3b9cf3e to 0a4f89e Compare April 28, 2026 05:13

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 9, 2026

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 11 pull requests #156371

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 9, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request May 9, 2026

Auto merge of #155509 - Walnut356:string_crash, r=<try>

89a60ef

[Debug Info] Gracefully handle invalid `String`/`Vec` try-job: aarch64-apple

This comment has been minimized.

Sign in to view

move string read logic to standalone function

23bd862

Walnut356 force-pushed the string_crash branch from 0a4f89e to 23bd862 Compare May 10, 2026 05:49

	# technically length isn't a NoHighBit<usize>, but if length should always be <= capacity
	# technically length isn't a NoHighBit<usize>, but length should always be <= capacity

Uh oh!

Conversation

Walnut356 commented Apr 19, 2026

Uh oh!

rustbot commented Apr 19, 2026

Uh oh!

Mark-Simulacrum left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Walnut356 Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Walnut356 Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Apr 26, 2026

Uh oh!

rustbot commented Apr 27, 2026

Uh oh!

Walnut356 commented Apr 27, 2026

Uh oh!

Mark-Simulacrum commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

JonathanBrouwer commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

Walnut356 commented May 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Mark-Simulacrum left a comment •

edited by rustbot

Loading